home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / doc / www-talk.archive.Z / www-talk.archive / text0145.txt < prev    next >
Encoding:
Text File  |  1992-11-30  |  9.3 KB  |  262 lines
  1.  
  2. ><!-- 
  3. >
  4. >  I first posted this some weeks ago on the 'www-interest' list, and 
  5. >  received only one reply, (complementing me on my reference to Rexx.)
  6. >
  7. I keep my copy of this posting handy and I check lots of ideas against it.
  8.  
  9. >  I really had hoped that this post would start an interesting discussion
  10. >  on the topics I address, specifically the ideas of 'attention links' 
  11. >  'user documents' and 'transparent documents'.
  12. >
  13. I don't have any well defined systems (implementations or just specs.)
  14. that address these issues. WWW is headed in this direction, but it's
  15. a long way off.
  16.  
  17. >  Are these ideas so obvious that they merit no discussion whatsoever?
  18. >
  19. No, it's more like they're so novel we haven't thought seriously enough
  20. to comment yet.
  21.  
  22. ><Query>
  23. >One of the missing pieces here is the ability of creating new h-texts, and
  24. >adding new links to old h-texts.
  25. >
  26. >Hypertext, and like systems, are of limited use if they do not support
  27. >collaboration.  I feel that this is a VERY important point.
  28. >
  29. >When might we expect extensions to WWW that support collaboration?
  30. ></Query>
  31.  
  32. You might look to Andrew for a more mature system in these regards.
  33. While I think Andrew is a great breeding ground for ideas, I think
  34. the resulting technology is too off-beat (for example, they implemented
  35. their own object-oriented C preprocessor, and now C++ has come along
  36. and writing Andrew code looks like a pain in comparison).
  37.  
  38. I'm toying with the idea of a FrameMaker inset editor to interface
  39. Frame's direct-manipulation editing capabilities with global
  40. hypertext on the internet. I shouldn't even mention it until I have
  41. some sort of implementation, but it's an idea...
  42.  
  43. >I have a few recommendations regarding new link types in WWW.  This is based
  44. >on thinking about hyper-applications for almost 15 years, (ever since I 
  45. >first had the pleasure of hearing Ted Nelson speak in 1977.)
  46. >
  47. >Please keep in mind that these are 'front end' issues.  They should not
  48. >affect the manner in which documents are stored.
  49. >
  50. Well, we should be careful not to store documents in a way that
  51. conflicts with these useful concepts.
  52.  
  53.  
  54. >------------------
  55. >
  56. >There are 4 'minimal' link types which, I believe, a true hypertext applicatio
  57. n
  58. >*must* support.
  59. >
  60. >    1.    Replacement
  61. >            -- when activated, replaces the current document
  62. >               with a new document, (this is what WWW offers
  63. >               today).
  64. >
  65. FrameMaker: gotolink
  66. GNU Info: menus, notes
  67. WWW: <A HREF=...>
  68. EBT: link
  69.  
  70. >    2.    Annotation
  71. >            -- when activated, overlays a new document on the
  72. >               current document, partially obscuring the original.
  73. >               (An annotation must be dismissed by the reader.)
  74. >
  75. FrameMaker: openlink
  76. GNU Info: n/a
  77. WWW: n/a
  78. EBT: link window=new
  79.  
  80. >    3.    Inclusion
  81. >            -- when the document is created, elements from other
  82. >               documents are collection to be included in the
  83. >               representation of the current document.  (Quotes)
  84. >               (This is a non-interactive link.  The user does
  85. >                not activate this link. It is activated before 
  86. >                the document is presented to the user.)
  87. >
  88. FrameMaker: import by reference (bitmapped graphics ONLY)
  89. GNU Info: n/a
  90. WWW: n/a
  91. EBT: n/a
  92.  
  93. >    4.    Expansion
  94. >            -- when activated, new information is added to the 
  95. >               current document, expanding the original scope.
  96. >
  97. FrameMaker: conditional text
  98. GNU Info: n/a
  99. WWW: n/a
  100. EBT: change stylesheets so that HIDE property changes
  101.  
  102. >
  103. >There are 3 further types which I believe are necessary to complete the
  104. >function paradigm.  (Of particular interest is the 'attention link'.)
  105. >
  106. >
  107. >    6.    Execution
  108. >
  109. >            -- when activated, some arbitrary function is performed
  110. .
  111. >               The point that was mentioned about the lack of an
  112. >               ubiquitious scripting language is well made.  Lisp
  113. >               is too arcane for most.  Shell languages are too
  114. >               platform specific.  What is needed is a simple
  115. >               to understand, freely available scripting platform.
  116. >               Although I hesitate to mention it, REXX might be
  117. >               a reasonable choice due to it's broad availability.
  118. >
  119. Ah... if you want commentary, state an arguable thesis. No one can argue
  120. against a platitude like "What is needed is a simple to undertand,
  121. freely available scripting platform." I vote for some brand of Lisp, perhaps
  122. XLisp or ELK.
  123.  
  124. But there's a larger issue: should documents be turing machines? Using SGML,
  125. it is a well defined problem to determine whether a document is valid. As
  126. soon as we allow documents to be programs (like TeX, nroff, or Lisp), we
  127. run into the halting problem and we lose any hope of converting documents
  128. from one representation to another. If a document is a program that, when run,
  129. conveys its content, then we lose the ability to use that content in any
  130. other way than the author originally intended.
  131.  
  132. >    5.    Attention   (a specialisation of the Execution type)
  133. >
  134. >            -- when the current document is modified (a link is
  135. >               added, or removed, or the document is merely read)
  136. >               a message is sent to the 'owner' of the attention
  137. >               link.  This message creates a new link in the 'user
  138. >               document' of the individual who placed the attention.
  139.  
  140. Hmmm... I need a clear explanation of the underlying model here. In the
  141. model in my mind, a "document" is never modified. But the functionality
  142. you describe is interesting. Certainly we want to be able to collect
  143. usage statistics.
  144.  
  145. >    7.    Collection  (a non-local specialisation of the Execution type)
  146. >
  147. >            -- when activated, a collection link leaves the current
  148. >               document, and 'travels' the docuverse, in search of
  149. >               other documents which satisfy it's internal criteria.
  150. >
  151. >               This is the concept of a 'knowbot'.
  152. >
  153. It looks like a query to me. I need either 1) a good definition of the
  154. capabilities of a knowbot, or 2) an implementation of a knowbot (any
  155. sort of hack will do) to get a feel for the functionality. Until
  156. then, it's just a very vague idea. Fortunately, there are some
  157. implementations of this idea: cron/find, WAIS, USENET news (kill files, etc.)
  158.  
  159. >
  160. >    Transparent Documents  --
  161. >
  162. >        a transparent document is one which a user creates locally,
  163. >        and that is a new representation of an existing document.
  164. >
  165. >        Transparent documents are used to create new local links on
  166. >        a document which I do not have permission to modify.
  167. >
  168. >        Transparent documents can then be made available to others,
  169. >        (published) just as a "regular" document is, thus facilitating
  170. >        the creation of new works from old.
  171. >
  172. This looks like a local copy of a document to me. No?
  173.  
  174. >    User Documents --
  175. >
  176. >        a user document is where I keep my "bookmarks", links to
  177. >        local documents, links to messages from others, links to
  178. >        my "attention" links, (see below).  User documents are where
  179. >        we, as navigators of the docuverse, are defined as individuals.
  180. >
  181. >        They are also where we can keep links to other user documents
  182. >        which have been permitted to view/modify my own local documents
  183. .
  184. >
  185. >        Another function of the User document is to collect users into
  186. >        an abstract group. (Thus, based on my membership in user 
  187. >        document 'Research Group', I am permitted access to materials
  188. >        'owned' by that group. Of course, messages sent to an abstract
  189. >        group then become available to all members of that group.)
  190. >
  191. >        (Please note that a User Document is nothing more or less than
  192. >         a collection of links, (as all documents are).)
  193. >
  194. Now we've opened up the whole PIM can of worms. Current implementations
  195. include mail user agents (MH, Elm), news readers (with their .newsrc and
  196. kill files, etc.) wais-questions, WWW home documents. I haven't looked
  197. at the hyperbole model, but I understand it addresses this issue at length.
  198.  
  199. >So.....
  200. >
  201. >    Scenerio:
  202. >
  203. I'd like to see how a MIME user agent would satisfy this scenario...
  204.  
  205. >        I start my session with my hypertext-application, and open 
  206. >        my user document.
  207. >
  208. I start my MIME UA.
  209.  
  210. >        I notice that 17 of my attention links have been activated 
  211. >        in the last day.
  212. >
  213. There are 17 mail messages (with certain tell-tale headers) in my inbox.
  214.  
  215. >        I select the most interesting and activate the link which
  216. >        it created in my personal user document.
  217. >
  218. I read the message. It's a message/external-body type message that points
  219. to an article in a USENET database at this site.
  220.  
  221. >        I am now reading an article which I previously linked
  222. that is, I had saved the article by creating a message/external-body
  223. type message in my mail box.
  224.  
  225. >        , and
  226. >        see that an annotation which I made some time ago
  227. i.e. my followup article
  228.  
  229. >         has been
  230. >        added to, by a colleague.
  231. >
  232. i.e. has been followed-up.
  233.  
  234. >        The comments are pertinant to my current work, so I create
  235. >        a new local 'transparent' document to mirror the original 
  236. >        work.  (Or use the 'transparent' document I may have created
  237. >        previously.)
  238. >
  239. I just save a reference to the news artile, as above, in a message/external-body
  240. type message.
  241.  
  242. >        On this new document, I make a few new annotations
  243.  
  244. i.e. I follow up to the document. It would be nice to be able to do
  245. some direct-manipulation style annotation to articles, ala FrameMaker.
  246.  
  247. >        and decide
  248. >        to made this new work available to the research group of which
  249. >        I am leader.  I place a link to it in the user document which
  250. >        represents my working group.
  251. >
  252. I mail a message/external-body style reference to the thread to the
  253. alias that represents my working group.
  254.  
  255. I really think that Internet Mail, Usenet News, and WAIS could be
  256. a great platform for CSCW. A MIME user agent that could make
  257. WAIS and NNTP queries and act as a FrameServer client would
  258. be a great start. If I have time, I'll try to cook something up.
  259.  
  260. Dan
  261.  
  262.